Alert management utilizing mobile devices

ABSTRACT

Methods, computer systems, and computer-storage medium are provided for managing patient alerts using a mobile device. A mobile device associated with a patient caregiver receives a critical alert related to the patient, and the alert is presented on the mobile device. The alert includes important contextual information that enables the caregiver to make a quick assessment of how to effectively address the alert. The alert includes options for accepting the alert or rejecting the alert. Acceptance of the alert enables the caregiver to communicate the alert to selected caregivers that can assist in managing the alert. Rejecting the alert causes the alert to be automatically communicated to additional caregivers associated with patient.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/179,096, filed Nov. 2, 2018, and entitled “Alert Management UtilizingMobile Devices,” which is a continuation of U.S. application Ser. No.15/873,158, filed Jan. 17, 2018 and entitled “Alert Management UtilizingMobile Devices,” subsequently issued as U.S. Pat. No. 10,121,346, whichis a continuation of U.S. application Ser. No. 15/684,563, filed Aug.23, 2017 and entitled “Alert Management Utilizing Mobile Devices,”subsequently issued as U.S. Pat. No. 9,911,300, which is a divisional ofU.S. application Ser. No. 15/630,617, filed Jun. 22, 2017 and entitled“Alert Management Utilizing Mobile Devices,” subsequently issued as U.S.Pat. No. 9,836,940, which is a continuation of U.S. application Ser. No.15/392,926, filed Dec. 28, 2016 and entitled “Alert Management UtilizingMobile Devices,” subsequently issued as U.S. Pat. No. 9,805,573, whichis a continuation of U.S. application Ser. No. 14/877,808, filed Oct. 7,2015 and entitled “Alert Management Utilizing Mobile Devices,”subsequently issued as U.S. Pat. No. 9,582,978, which is a continuationof U.S. application Ser. No. 13/731,191, filed Dec. 31, 2012 andentitled “Alert Management Utilizing Mobile Devices,” subsequentlyissued as U.S. Pat. No. 9,185,202. The entirety of the aforementionedapplications is incorporated by reference herein.

BACKGROUND

Typical nurse management of patient alerts utilizes stationary computerterminals located at, for example, a nursing station associated with anursing unit. The stationary terminals are manned by unit secretarieswho receive alerts or other important information related to patients onthe unit. The unit secretary then identifies the caregivers assigned tothose patients and may attempt to contact the caregivers through avariety of methods such as electronic paging, calling a patient's roomto see if the caregiver is in the room, or overhead paging. Caregiversthen either have to call the unit secretary or return to the nursingstation to retrieve the alerting information. The result is inefficientcommunication, unproductive workflows, and time lags between whenalerting information is received and when it is acted on by thecaregiver.

In those situations where a patient alert is pushed to a caregiver'smobile device, the alert often lacks important patient-contextualinformation, such as medical values, images, or device readingsassociated with the alert, that help the caregiver in deciding how toappropriately respond to the alert. The caregiver must then eitherreturn to the nursing station to access the information or open up acomputer application on the mobile device to access the neededinformation—both of which consume valuable time resources. Further,though the caregiver may receive an alert, the caregiver is generallynot given an opportunity to further interact with the alert. Forinstance, the alert generally cannot be communicated to anothercaregiver that can assist in addressing the alert.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter. The present invention is defined by the claims.

In brief and at a high level, this disclosure describes, among otherthings, methods, systems, and computer-storage media for managingpatient alerts using mobile devices. A patient alert is received andpresented on a caregiver's mobile device; the caregiver is part of thepatient's care team. The alert includes patient-identifying informationalong with the alert identifier and contextual patient data related tothe alert. If the alert is a critical alert, the alert must beacknowledged in some manner before the caregiver can resume use of themobile device. Acknowledgment of the alert may comprise rejecting thealert or accepting the alert. Rejection of the alert by the caregivercauses the alert to be automatically communicated to another caregiverassigned to the patient. Acceptance of the alert by the caregiverenables the caregiver to access members of the patient's care team andto forward the alert on to selected members of the team that can assistthe caregiver in addressing the alert.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are described in detail below with reference to the attacheddrawing figures, wherein:

FIG. 1 is a block diagram of an exemplary computing environment suitableto implement embodiments of the present invention;

FIG. 2 is a block diagram of an exemplary system for managing patientalerts suitable to implement embodiments of the present invention;

FIG. 3 is a flow diagram of an exemplary method of accepting andmanaging patient alerts using a mobile device in accordance with anembodiment of the present invention;

FIG. 4 is a flow diagram of an exemplary method of managing patientalerts when an alert is rejected in accordance with an embodiment of thepresent invention;

FIG. 5 is a series of exemplary graphical user interfaces illustratingthe acceptance and management of patient alerts in accordance with anembodiment of the present invention;

FIG. 6 is a series of exemplary graphical user interfaces illustratingthe ability to see trending data related to a patient alert inaccordance with an embodiment of the present invention;

FIG. 7 is a series of exemplary graphical user interfaces illustratingthe ability to utilize reminders with non-critical alerts in accordancewith an embodiment of the present invention;

FIG. 8 is an exemplary graphical user interface illustrating theadditional information presented with an alert in accordance with anembodiment of the present invention;

FIG. 9 is a series of exemplary graphical user interfaces illustratingthe ability of a caregiver to review an alert history in accordance withan embodiment of the present invention; and

FIG. 10 is a flow diagram of an exemplary method of receiving an alertthat includes patient-contextual information related to the alert usinga mobile device in accordance with an embodiment of the presentinvention.

DETAILED DESCRIPTION

The subject matter of the present invention is described withspecificity herein to meet statutory requirements. However, thedescription itself is not intended to limit the scope of this patent.Rather, the inventors have contemplated that the claimed subject mattermight also be embodied in other ways, to include different steps orcombinations of steps similar to the ones described in this document, inconjunction with other present or future technologies. Moreover,although the terms “step” and/or “block” may be used herein to connotedifferent elements of methods employed, the terms should not beinterpreted as implying any particular order among or between varioussteps herein disclosed unless and except when the order of individualsteps is explicitly described.

Embodiments of the present invention are directed to methods, systems,and computer-storage media for managing patient alerts using mobiledevices. A patient alert is received and presented on a caregiver'smobile device; the caregiver is part of the patient's care team. Thealert includes patient-identifying information along with the alertidentifier and contextual medical data related to the alert. If thealert is a critical alert, the alert must be acknowledged in some mannerbefore the caregiver can resume use of the mobile device. Acknowledgmentof the alert may comprise rejecting the alert or accepting the alert.Rejection of the alert by the caregiver causes the alert to beautomatically communicated to another caregiver assigned to the patient.Acceptance of the alert by the caregiver enables the caregiver to accessmembers of the patient's care team and to forward the alert on toselected members of the team that can assist the caregiver in addressingthe alert.

An exemplary computing environment suitable for use in implementingembodiments of the present invention is described below. FIG. 1 is anexemplary computing environment (e.g., medical-informationcomputing-system environment) with which embodiments of the presentinvention may be implemented. The computing environment is illustratedand designated generally as reference numeral 100. The computingenvironment 100 is merely an example of one suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the invention. Neither should thecomputing environment 100 be interpreted as having any dependency orrequirement relating to any single component or combination ofcomponents illustrated therein.

The present invention might be operational with numerous other purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that might besuitable for use with the present invention include personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of theabove-mentioned systems or devices, and the like.

The present invention might be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Exemplary program modules comprise routines,programs, objects, components, and data structures that performparticular tasks or implement particular abstract data types. Thepresent invention might be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules might be located in association with localand/or remote computer storage media (e.g., memory storage devices).

With continued reference to FIG. 1, the computing environment 100comprises a computing device in the form of a control server 102.Exemplary components of the control server 102 comprise a processingunit, internal system memory, and a suitable system bus for couplingvarious system components, including data store 104, with the controlserver 102. The system bus might be any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, and a local bus, using any of a variety of bus architectures.Exemplary architectures comprise Industry Standard Architecture (ISA)bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus,Video Electronic Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus, also known as Mezzanine bus.

The control server 102 typically includes therein, or has access to, avariety of computer-readable media. Computer-readable media can be anyavailable media that might be accessed by control server 102, andincludes volatile and nonvolatile media, as well as, removable andnonremovable media. By way of example, and not limitation,computer-readable media may comprise computer storage media andcommunication media. Computer storage media includes both volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canbe accessed by control server 102. Communication media typicallyembodies computer-readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer-readable media.

The control server 102 might operate in a computer network 106 usinglogical connections to one or more remote computers 108. Remotecomputers 108 might be located at a variety of locations in a medical orresearch environment, including clinical laboratories (e.g., moleculardiagnostic laboratories), hospitals and other inpatient settings,veterinary environments, ambulatory settings, medical billing andfinancial offices, hospital administration settings, home healthcareenvironments, and clinicians' offices. Clinicians may comprise atreating physician or physicians; specialists such as surgeons,radiologists, cardiologists, and oncologists; emergency medicaltechnicians; physicians' assistants; nurse practitioners; nurses;nurses' aides; pharmacists; dieticians; microbiologists; laboratoryexperts; laboratory technologists; genetic counselors; researchers;veterinarians; students; and the like. The remote computers 108 mightalso be physically located in nontraditional medical care environmentsso that the entire healthcare community might be capable of integrationon the network. The remote computers 108 might be personal computers,servers, routers, network PCs, peer devices, other common network nodes,or the like and might comprise some or all of the elements describedabove in relation to the control server 102. The devices can be personaldigital assistants or other like devices.

Computer networks 106 comprise local area networks (LANs) and/or widearea networks (WANs). Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets, and the Internet.When utilized in a WAN networking environment, the control server 102might comprise a modem or other means for establishing communicationsover the WAN, such as the Internet. In a networking environment, programmodules or portions thereof might be stored in association with thecontrol server 102, the data store 104, or any of the remote computers108. For example, various application programs may reside on the memoryassociated with any one or more of the remote computers 108. It will beappreciated by those of ordinary skill in the art that the networkconnections shown are exemplary and other means of establishing acommunications link between the computers (e.g., control server 102 andremote computers 108) might be utilized.

In operation, an organization might enter commands and information intothe control server 102 or convey the commands and information to thecontrol server 102 via one or more of the remote computers 108 throughinput devices, such as a keyboard, a pointing device (commonly referredto as a mouse), a trackball, or a touch pad. Other input devicescomprise microphones, satellite dishes, scanners, or the like. Commandsand information might also be sent directly from a remote healthcaredevice to the control server 102. In addition to a monitor, the controlserver 102 and/or remote computers 108 might comprise other peripheraloutput devices, such as speakers and a printer.

Although many other internal components of the control server 102 andthe remote computers 108 are not shown, such components and theirinterconnection are well known. Accordingly, additional detailsconcerning the internal construction of the control server 102 and theremote computers 108 are not further disclosed herein.

Turning now to FIG. 2, an exemplary computing system environment 200 isdepicted suitable for use in implementing embodiments of the presentinvention. The computing system environment 200 is merely an example ofone suitable computing system environment and is not intended to suggestany limitation as to the scope of use or functionality of embodiments ofthe present invention. Neither should the computing system environment200 be interpreted as having any dependency or requirement related toany single module/component or combination of modules/componentsillustrated therein.

The computing system environment 200 includes an alert service 210, adata store 212, and a mobile device 214 all in communication with oneanother via a network 216. The network 216 may include, withoutlimitation, one or more secure local area networks (LANs) or wide areanetworks (WANs). The network 216 may be a secure network associated witha facility such as a healthcare facility. The secure network 216 mayrequire that a user log in and be authenticated in order to send and/orreceive information over the network 216.

In some embodiments, one or more of the illustrated components/modulesmay be implemented as stand-alone applications. In other embodiments,one or more of the illustrated components/modules may be integrateddirectly into the operating system of the alert service 210. Thecomponents/modules illustrated in FIG. 2 are exemplary in nature and innumber and should not be construed as limiting. Any number ofcomponents/modules may be employed to achieve the desired functionalitywithin the scope of embodiments hereof. Further, components/modules maybe located on any number of servers. By way of example only, the alertservice 210 might reside on a server, cluster of servers, or a computingdevice remote from one or more of the remaining components.

It should be understood that this and other arrangements describedherein are set forth only as examples. Other arrangements and elements(e.g., machines, interfaces, functions, orders, and groupings offunctions, etc.) can be used in addition to or instead of those shown,and some elements may be omitted altogether. Further, many of theelements described herein are functional entities that may beimplemented as discrete or distributed components or in conjunction withother components/modules, and in any suitable combination and location.Various functions described herein as being performed by one or moreentities may be carried out by hardware, firmware, and/or software. Forinstance, various functions may be carried out by a processor executinginstructions stored in memory.

The data store 212 is configured to store information for use by, forexample, the alert service 210 and/or the mobile device 214. Theinformation stored in association with the data store 212 is configuredto be searchable for one or more items of information stored inassociation therewith. The information stored in association with thedata store 212 may comprise general information used by the alertservice 210 and/or the mobile device 214.

The data store 212 may store electronic medical records (EMRs) ofpatients associated with one or more healthcare facilities. EMRs maycomprise electronic clinical documents such as images, clinical notes,orders, summaries, reports, analyses, or other types of electronicmedical documentation relevant to a particular patient's conditionand/or treatment. Electronic clinical documents contain various types ofinformation relevant to the condition and/or treatment of a particularpatient and can include information relating to, for example, patientidentification information, images, alert history, culture results,physical examinations, vital signs, past medical histories, surgicalhistories, family histories, histories of present illnesses, current andpast medications, allergies, symptoms, past orders, completed orders,pending orders, tasks, lab results, other test results, patientencounters and/or visits, immunizations, physician comments, nursecomments, other caretaker comments, and a host of other relevantclinical information.

Additionally, the data store 212 may store information concerningdecision-support algorithms, reference materials, standards of care,recommendation protocols, alert protocols, and the like. Thisinformation may be specific to a healthcare facility, or the informationmay be promulgated by, for example, nationally-recognized medicalorganizations or governing bodies. Information stored in the data store212 may also include staffing assignments (e.g., which caregivers areassigned to care for a patient), and availability information for thedifferent caregivers. For instance, a caregiver who is logged into thenetwork 216 is flagged as available; a caregiver who is logged into thenetwork 216 but who has indicated that he/she is busy is flagged asavailable but busy; and a caregiver who is not logged into the network216 is flagged as offline. Staffing and availability information iscontinually updated. As used throughout this application, the term“caregiver” generally means healthcare workers such as registerednurses, aids, respiratory therapists, physical therapists, occupationaltherapists, and the like. Caregivers such as these provide theday-to-day care of patients but normally do not have orderingprivileges.

The content and volume of such information in the data store 212 are notintended to limit the scope of embodiments of the present invention inany way. Further, though illustrated as a single, independent component,the data store 212 may, in fact, be a plurality of storage devices, forinstance, a database cluster, portions of which may reside on the alertservice 210, the mobile device 214, and/or any combination thereof.

The mobile device 214 may be any type of wireless-telecommunicationsdevice. Such devices may include any type of mobile and portable devicesincluding cellular telephones, personal digital assistants, tablet PCs,smart phones, and the like. The mobile device 214 includes a set ofembodied computer-executable instructions 215 that carry out variousfunctional aspects of the invention. In one aspect, the mobile device214 may be associated with or assigned to a caregiver by the healthcarefacility. In another aspect, the mobile device 214 may be owned by thecaregiver and registered with the healthcare facility. The mobile device214 is capable of communicating with other associated or registeredmobile devices by utilizing the secure network 216.

As shown, the mobile device 214 includes a display screen. The displayscreen is configured to display information to the user of the mobiledevice 214. The information may include communications initiated byand/or received by the mobile device 214, patient alerts, medical datarelated to the patient alerts, care lists, availability information, andthe like. Embodiments are not intended to be limited to visual displaybut rather may also include audio presentation, combined audio/visualpresentation, and the like.

Components of the alert service 210 and the mobile device 214 mayinclude a processing unit, internal system memory, and a suitable systembus for coupling various system components, including one or more datastores for storing information (e.g., files and metadata associatedtherewith). The alert service 210 and the mobile device 214 typicallyinclude, or has access to, a variety of computer-readable media.

The computing system environment 200 is merely exemplary. While thealert service 210 is illustrated as a single unit, it will beappreciated that the alert service 210 is scalable. For example, thealert service 210 may in actuality include a plurality of computingdevices in communication with one another. Moreover, the data store 212,or portions thereof, may be included within, for instance, the alertservice 210 and the mobile device 214 as a computer-storage medium. Thesingle unit depictions are meant for clarity, not to limit the scope ofembodiments in any form.

As shown in FIG. 2, the alert service 210 comprises a receivingcomponent 218, an alerting component 220, and a communicating component222. In some embodiments, one or more of the components 218, 220, and222 may be implemented as stand-alone applications. In otherembodiments, one or more of the components 218, 220, and 222 may beintegrated directly into the operating system of a computing device suchas the remote computer 108 of FIG. 1 or the mobile device 214. It willbe understood that the components 218, 220, and 222 illustrated in FIG.2 are exemplary in nature and in number and should not be construed aslimiting. Any number of components may be employed to achieve thedesired functionality within the scope of embodiments hereof.

The receiving component 218 is configured to receive information relatedto patient alerts. Such information may include data from medicaldevices electronically associated with a patient. Such devices arenumerous but representative examples may include respirators, pulseoximeters, blood pressure monitors, blood glucose monitors, heartrate/rhythm monitors, input/output monitors, fetal monitors, and thelike. Data from medical devices includes values, waveform tracings,images, and the like. The receiving component 218 may also receivepatient-identifying information from, for example, the data store 212along with an alert history for the patient and normal value ranges forthe patient.

Continuing, the receiving component 218 is further configured to receivestaffing assignments from, for example, the data store 212 or astaffing/scheduling system associated with the healthcare facilitycaring for the patient. Staffing assignments include caregivers assignedto care for the patient during a specified time frame. Staffingassignments may depend on the patient's medical condition. By way ofillustrative example, a patient who is rehabilitating from a serious caraccident may be assigned a primary caregiver (e.g., a nurse), asecondary caregiver that cares for the patient when the primarycaregiver is busy, a respiratory therapist, a physical therapist, and anoccupational therapist.

The receiving component is additionally configured to receiveavailability information for each of the patient's assigned caregivers.This information may be stored in association with the data store 212 orwith the staffing/scheduling system. The availability status for any onecaregiver may include the status of available, available but busy, andoffline. The status of available occurs when the caregiver is logged inand authenticated to the secure network 216. The status of available butbusy occurs when the caregiver is logged in but has marked himself asbusy using, for example, the mobile device 214. The status of offlineoccurs when the caregiver is logged off of the network 216.

The receiving component 218 also receives location information for thecaregivers, the patient, and devices associated with the patient from,for example, a real-time location service associated with the healthcarefacility. Such services use a variety of methods known in the art totrack location information including radio-frequency identification(RFId) tags and sensors located throughout the healthcare facility.

The receiving component additionally receives information from the nursecall system of the healthcare facility. The nurse call system enablescommunication between the patient and caregivers utilizing a number ofdifferent devices such as a pillow speaker. Some systems enable thepatient to enter information concerning the nurse call before it istransmitted to the nurse. For instance, the patient may input thathe/she would like ice chips, or that he/she is having difficultybreathing or is in pain.

The alerting component 220 is configured to use the information receivedby the receiving component 218 to generate alerts. The alertingcomponent 220 may utilize the information in association with clinicalguidelines, alerting protocols, and/or standardized recommendations todetermine if and what type of alert should be generated. The alerts canbe broadly categorized as critical alerts and non-critical alerts.Critical alerts can be generally defined as those alerts that can have anegative impact on a patient's health if not addressed in a timelymanner. On the other hand, non-critical alerts can be generally definedas those alerts that do not negatively impact the patient's health ifnot addressed in a timely manner. Some representative examples ofcritical alerts may include a heart arrhythmia, low oxygen saturation,low respiratory rate, elevated blood pressure, presence of sepsisindicators, and the like. Some representative examples of non-criticalalerts include patient requests for ice chips or toiletry assistance,lab values or device readings that are slightly outside of the normalrange, indication that a new patient order has been received, and thelike.

The communicating component 222 is configured to communicate patientalerting information to the mobile device 214. The alerting informationincludes an alert identifier, status indicators related to the alert,patient-identifying information, lab values related to the alert,medication orders related to the alert, and device readings related tothe alert. In one aspect, lab values, medication orders, and devicereadings (e.g., waveform tracings, values, and/or images) are related tothe alert if they triggered the alert. The waveform tracings, values,and/or images may be time-stamped and may include a predefined timeperiod before the alert was triggered, a time period corresponding tothe alert trigger, as well as a predefined time period after the alertwas triggered. The mobile device 214 then presents this information tothe caregiver as more fully described below.

In one aspect, the communicating component 222 communicates thepatient's alerting information initially to the mobile device associatedwith the patient's primary caregiver. If the primary caregiver rejectsthe alert, the communicating component 222 may next communicate thepatient's alerting information to the mobile device associated with thepatient's secondary caregiver. If the secondary caregiver rejects thealert, the communicating component 222 may communicate the patient'salerting information to the mobile device associated with the chargenurse of the patient's unit. If the charge nurse rejects the alert, thecommunicating component 222 may communicate the alert to mobile devicesassociated with every member of the patient's care team.

In another aspect, the communicating component 222 determines thecaregiver role best suited to initially address the particular patientalert, and communicates the alerting information to mobile devicesassociated with caregivers in that role. By way of illustrative example,a patient alert indicates that a patient's oxygen saturation levels havedropped below recommended ranges. The communicating component 222determines that a respiratory therapist would be suited to address thisalert and communicates the alerting information to the mobile deviceassociated with the respiratory therapist. The alerting information mayat the same time be communicated to the mobile device associated withthe patient's primary caregiver.

In yet another aspect, the communicating component 222 determinescaregivers in close proximity to the patient that is the subject of thealert, determines if the role of those caregivers that are located closeto the patient is suited to meet the particular patient alert, and, ifso, communicates the initial alert to those caregivers. The alertinginformation may at the same time be communicated to the mobile deviceassociated with the patient's primary caregiver. Any and all of suchaspects, and any combination thereof, are contemplated as being withinthe scope of the invention.

The communicating component 222 is further configured to receivecommunications from the mobile device 214. Such communications maycomprise notifications that the alert has been acknowledged and acceptedby the recipient. This information is time-stamped and may be stored inassociation with the patient's electronic medical record. Anothercommunication may comprise a notification that the alert was rejected bythe recipient. Other communications from the mobile device may includeindicators that the recipient of the alert has communicated the alert toother members of the care team. The indicators may include theidentities of the additional recipients, whether the additionalrecipients acknowledged receipt of the alert, and a time the alert wasforwarded. Communications from the mobile device 214 may additionallyinclude requests for more information.

Turning now to FIG. 3, a flow diagram is depicted of an exemplary method300 of managing patient alerts on a mobile device. At a step 310, afirst mobile device such as the mobile device 214 of FIG. 2 receives analert related to a patient being cared for at a healthcare facility. Inone aspect, the alert may be received from a communicating component ofan alert service such as the communicating component 222 of the alertservice 210. In another aspect, the alert may have been communicated byanother mobile device. The first mobile device, in one aspect, haspreviously been registered, associated with or assigned to a member ofthe patient's care team such as the patient's primary and/or secondarycaregiver. The receipt of the alert may be accompanied by an auditorysound or a physical action such as a vibration to alert the caregiverthat an alert has been received.

At a step 312, the alert is presented on the first mobile device. If thealert is a critical alert, the alert is configured to interrupt orsupersede any applications that are currently running on the firstmobile device. For instance, the alert may be presented as a pop-up thatoverlies other content on the mobile device. The caregiver cannot accessother functionalities associated with the first mobile device until thecaregiver acknowledges the alert by either accepting or rejecting thealert. This helps to ensure that critical alerts are addressed in atimely manner by the caregiver.

The alert presented on the first mobile device includespatient-identifying information such as the patient's name, roomlocation, and the patient's date of birth. The alert also includes analert identifier and an alert status. The alert identifier conveys tothe caregiver the nature of the alert. For instance, identifiers mayinclude phrases such as “ADE” for an adverse drug event, “HR high” toindicate the heart rate is outside of the normal range, “Low SPO2” toindicate low blood oxygen saturation, “Diastolic High” to indicate thatdiastolic blood pressure is high, and “SEPSIS: SIRS Criteria Met” toindicate that the patient is possibly becoming septic. These are just afew representative examples provided for illustration purposes only. Anyidentifier that provides a brief description of the nature of the alertis contemplated as being within the scope of the invention. The alertstatus may be indicated by textual phrases such as “Critical Alert,”color coding, flashing images, and the like.

The alert may also comprise a short summary of lab values, medications,images, or device readings that are pertinent to the alert. In oneaspect, the values, medications, images, or device readings thattriggered the alert are presented in the short summary. The devicereadings may include a snippet of a waveform tracing or trending graphthat was taken by the monitoring device at the time the alert wastriggered. The snippet may be time-stamped and may include a time periodbefore the alert, a time period during the alert, and a time periodafter the alert was triggered. For instance, an elevated heart ratealert may include the detected heart rate along with a snippet of aheart rate rhythm waveform tracing captured around the time the alertwas triggered. This important patient-contextual information ispresented in association with the alert to assist the caregiver inmaking a quick assessment of the alert situation. The alert may alsoinclude options for accepting the alert or rejecting the alert.Exemplary options include an accept icon, button or bar, and a rejecticon, button or bar.

At a step 314, an acceptance of the alert by the caregiver is receivedby the first mobile device. The caregiver may accept the alert bytapping, swiping, or otherwise selecting, for example, the acceptanceicon, bar, or button. Once selected, at a step 316, a list of one ormore additional caregivers assigned to the patient is presented on thefirst mobile device. The list may include the names of the othercaregivers, a thumbnail picture of the caregiver, roles associated witheach of the caregivers, locations of the caregivers, and/or theavailability status of the caregivers. The list may be ordered based oncaregiver role such that caregivers most suited to meet the alert needsare presented at the top of the list. The list may also be ordered basedon proximity to the patient location. Thus the recipient of the alertcan quickly assess which caregivers are located closest to the patient.The list may additionally be ordered based on a combination of user roleand proximity to the patient. Other ways of ordering the list includealphabetical order and availability status. Any and all such aspects,and any combination thereof, are contemplated as being within the scopeof the invention.

Caregivers on the list are associated with an availability statusindicator. These indicators may indicate that the caregiver isavailable, available but busy, or is not currently logged into thenetwork. Availability status indicators may include color-codedindicators such as green for available, white for offline, and red foravailable but busy. Other ways of indicating availability status mayinclude textual descriptions, and other types of visual indicators knownin the art.

At a step 316, a selection of one or more additional caregivers isreceived by the first mobile device. This may occur, for example, whenthe recipient of the alert selects a caregiver by tapping or swiping onthe caregiver's information. Once selected, at a step 318, the firstmobile device communicates the alert to at least a second mobile deviceassociated with the selected caregiver. In one aspect, the originalrecipient of the alert can simply call a caregiver on the list. Inanother aspect, the alert is communicated as a short message service(SMS) message or a multimedia message service (MMS) message. The alertthat is communicated to the selected caregiver includes thepatient-identifying information, the alert identifier, the alert status,and lab values, device readings, medication orders, images, and/ortrending graphs associated with the alert. Further, when the alert iscommunicated as a SMS message or a MMS message, the original recipientmay optionally enter a textual message in association with the alert. Inone aspect, the original recipient receives a notification when theselected caregiver acknowledges the alert.

Turning now to FIG. 4, a flow diagram is depicted illustrating anexemplary method 400 of managing patient alerts using a mobile device.At a step 410, a patient alert is received on a first mobile device suchas the mobile device 214 of FIG. 2. The patient alert may becommunicated to the first mobile device by an alert service such as thealert service 210 of FIG. 2. The first mobile device is associated withor assigned to a member of the patient's care team, such as thepatient's primary or secondary caregiver.

At a step 412, if the alert is a critical alert, the alert is presentedon the first mobile device such that it interrupts or supersedes anycurrently running applications on the mobile device. The alert may bereceived and presented in association with an audible sound, and/or aphysical action such as a vibration. If the alert is a non-criticalalert, the recipient may be notified of the alert via a pop-up message,or the alert may be briefly presented. Non-critical alerts generally donot supersede currently running applications on the mobile device. Asdiscussed above, the critical alert includes patient-identifyinginformation, the alert identifier, the alert status, lab values, devicereadings, images, trending graphs, and/or waveform tracings that arerelated to the alert, and options for accepting or rejecting the alert.

At a step 414, a rejection of the alert is received by the first mobiledevice. In one aspect, the rejection may be initiated by the alertrecipient affirmatively selecting a rejection button, icon, bar, or thelike. The recipient caregiver may reject the alert if he or she iscurrently busy and cannot address the alert in a timely manner. At astep 416, the alert is automatically communicated to a second mobiledevice associated with at least a second caregiver assigned to care forthe patient. The selection of the second caregiver may be based on analerting protocol associated with, for example, a data store such as thedata store 212 of FIG. 2. The second caregiver may, in one aspect,comprise the secondary caregiver assigned to the patient. The alert mayautomatically be communicated to more than one additional caregiver.

The alert that is automatically communicated to the second mobile deviceat step 416 is substantially identical to the original alert. Forexample, it includes patient-identifying information, alert name, alertstatus, lab values, device readings, images, waveform tracings, and/ortrending graphs, along with options to accept or reject the alert. Thecaregiver associated with the second mobile device can accept the alertwhich initiates the steps outlined above with respect to FIG. 3.Alternatively, the caregiver associated with the second mobile devicecan reject the alert which initiates the steps outlined above withrespect to FIG. 4.

In one aspect, failure by the alert recipient to address the alertwithin a predetermined period of time causes the alert to beautomatically communicated to additional mobile devices such as mobiledevices associated with the patient's secondary caregiver, the chargenurse, or other caregivers on the patient's care team. The predeterminedperiod of time may range from one minute up to five minutes and may bedependent on the criticality of the alert.

FIG. 10 is a flow diagram of an exemplary method 1000 of receivingpatient-contextual information related to an alert on a mobile device.At a step 1010, a patient alert is received on a first mobile deviceassociated with a first caregiver caring for the patient. In one aspect,the first caregiver is the patient's primary caregiver. At a step 1012,the patient alert is presented on the first mobile device. The patientalert may include patient-identifying information such as patient name,age, gender, and room location. The alert may also include one or moreitems of patient information relevant to the alert. In one aspect,patient information is relevant to the alert if it triggered the alert.For example, a lab value that is outside the normal range may triggerthe alert, and the lab value would be presented on the mobile device.Patient information relevant to the alert may include lab values,medication orders, and/or device readings. Device readings, in turn, mayinclude waveform tracings, trending graphs, images, and the like.

Turning now to FIG. 5, a series of exemplary graphical user interfaces(GUIs) 500, 520, 540, and 560 are depicted; the series of GUIsillustrate how patient alerts are managed using a mobile device such asthe mobile device 214 of FIG. 2. GUI 500 is the first in the series anddepicts a critical alert 510 presented on the mobile device. The alert510 overlays existing content of the mobile device and is displayeduntil acted on by the recipient of the alert 510. The alert 510 includesa patient identification area 512 that presents information such aspatient name, patient identification number, room number, date of birth,and the like. The alert 510 also includes an alert identifier 514 and analert status 515. The alert identifier 514 (e.g., “ADE ALERT”) providesa brief description of the alert, and the alert status 515 indicatesthat the alert is critical. In one aspect, only critical alerts arepresented utilizing the methods described above. The alert 510additionally includes a selectable “reject” bar 516 and a selectable“accept” bar 518. Although bars are depicted, other selectable optionsare contemplated such as icons or buttons. The accept bar 518 has a calloption 517 and a message option 519. In one aspect, when the call option517 is selected, the recipient is automatically presented with a callcontact list comprising members of the patient care team. The callcontact list includes names of the caregivers, pictures of thecaregivers, availability indicators, location information, user role,and the like. In another aspect, when the call option 517 is selected, acall to the patient room is automatically placed so that the caregivercan speak with the patient. When the message option 519 is selected, therecipient is presented with a messaging GUI as shown in the GUI 540.

GUI 520 depicts the presentation of additional information 522associated with the alert 510. The additional information 522 may bepresented when the alert recipient selects, for example, the alertidentifier 514 or some other portion of the alert 510. The additionalinformation 522 may include such items as medications, lab values,device readings, and the like. Medication information may include thedosage amount, the dosage route, and the day and time when themedication was last administered. Lab value information and devicereading information may include a normal range, a previous value, acurrent value, a date and time when obtained, and an indicator thatindicates whether the current value is greater or lesser than theprevious value. Each of the items of information 522 provides patientcontext to the alert 510 and assist the alert recipient to make aninformed decision regarding how to effectively address the alert. TheGUI 520 also includes an acceptance area 524 that indicates the time thealert 510 was accepted by the recipient.

The GUI 540 may be presented when the recipient selects the messageoption 519, or when the recipient advances to the next screen utilizinga forward page icon as shown at item 526 on GUI 520. The GUI 540includes an alert depiction 544 that includes patient-identifyinginformation, the alert identifier, and the alert status. The alertdepiction 544 also includes a message area 545 where the recipient caninput a message. The GUI 540 also includes a selectable icon 542, that,when selected, initiates the presentation of a list of caregivers thatare on the patient's care team.

GUI 560 depicts the care team list 562 that is presented upon selectionof the selectable icon 542 of GUI 540. The care team list 562 includesall caregivers that are currently assigned to the patient. Usingcaregiver Ashley Gibbs 564 as an illustrative example, informationpresented in association with Ashley Gibbs 564 includes a picture 571, arole 566 (e.g., “RN”), a location 568 (e.g., “In Room”), and anavailability indicator 570. The availability indicator 570 may be colorcoded to indicate availability. For example, the indicator 570 may becolored green if the caregiver 564 is available, red if the caregiver564 is available but busy, and white if the caregiver 564 is offline.Further, for those users who are color-blind, the color coded indicatorsmay be placed in different locations so the user can distinguishbetween, for example, a red indicator and a green indicator. Forexample, green indicators may be presented on the right side of thescreen, and red indicators may be presented on the left side of thescreen.

The list 562 may be categorized by user role, availability status,and/or proximity to the patient. Although not shown, the alert recipientcan select by, for example, swiping, tapping, or using other gesturesknown in the art, one or more caregivers on the list and communicate thealert to the selected caregivers. The alert information 522 iscommunicated with the alert so that the selected caregivers can quicklyaccess the needed information.

FIG. 6 depicts a series of two exemplary GUIs 600 and 620 illustratingthe presentation of waveform tracings associated with a patient alert.GUI 600 includes an alert 610 that includes the information alreadyoutlined above with respect to, for example, the alert 510 of FIG. 5.The GUI 600 further includes a display icon 612. Selection of thedisplay icon 612 initiates the presentation of GUI 620. The GUI 620includes the alert 610 along with a waveform tracing 622. The waveformtracing 622 is captured and time-stamped by the patient's device at thetime the alert was triggered and may include segments of time before andafter the alert was triggered to provide additional context for thewaveform tracing. Although a waveform tracing is shown, it is alsocontemplated that an image captured by a camera or a monitoring devicemay be presented. For instance, a caregiver may take a picture of apatient's wound and this image may be included with the alert 610. Thewaveform tracing 622, and/or image, is used by the alert recipient toselect other caregivers to notify so that the alert can be properlyaddressed.

FIG. 7 depicts a series of exemplary GUIs 700, 720, 740, and 760 thatillustrate how reminders can be generated for non-critical alerts. GUI700 depicts an alert review screen 705 on which a non-critical alert 710has been selected. The alert review screen 705 may be accessed from ageneral menu (not shown). Non-critical alerts differ from criticalalerts in that they generally do not supersede any currently runningapplications. Non-critical alerts may be presented as a pop-up thatpersists for a short period of time before fading. The pop-up may bedismissed by the user by, for example, selecting a different area of thedisplay screen. Non-critical alerts may also be presented to thecaregiver on the mobile device as a notification message, and thecaregiver can review the alert at his/her discretion. Non-criticalalerts differ from critical alerts in that reminders may be set fornon-critical alerts. By contrast, because of the time-sensitive natureof critical alerts, reminders cannot be set for critical alerts.

The non-critical alert 710 includes an alert identifier 709, an alertstatus 713, a reject option 711, and an accept option 712. If thecaregiver chooses to accept the non-critical alert 710 by tapping,swiping, or otherwise selecting, a set of options 730 is presented asshown on the GUI 720. The GUI 720 includes the alert review screen 705.The set of options 730 includes a reminder option 732 to set a reminder,a call option 734 to call a caregiver or to call the patient's room, anda message option 736 to message a caregiver on the patient's care team.The alert review screen 705 in the GUI 720 also depicts new patientalerts 722 and previous patient alerts 724; the new patient alerts 722and the previous patient alerts 724 include both critical andnon-critical alerts. Each alert includes an alert identifier, and a timewhen the alert was triggered.

GUI 740 depicts the alert review screen 705 and a reminder screen 742that is initiated upon a user selection of the reminder option 732 inthe set of options 730 of GUI 720. The reminder screen 742 enables thecaregiver to select from a range of reminder times or to cancel thereminder. Reminder times may include 5 minutes, 10 minutes, 15 minutes,and 20 minutes.

GUI 760 depicts the alert review screen 705 after a reminder time hasbeen selected. As shown by alert 762, the non-critical alert for icechips is now associated with a reminder time of 5 minutes. Further, area764 is a visual indicator that one or more reminders have been initiatedfor non-critical alerts. The area 764 includes the names of alerts thathave been associated with a reminder, as well as an indicator to drawthe user's attention to the area 764 (e.g., an exclamation point).

FIG. 8 depicts an exemplary GUI 800 illustrating additional informationthat may be associated with a critical alert. The GUI 800 includes acritical alert 810. The critical alert 810 includes the same informationas outlined above with respect to the alert 510 of FIG. 5. The alert 810may further include a number of people that were sent the alert asindicated by element 812. Thus, in this case, the alert 810 wascommunicated to three caregivers associated with the patient. The alert810 also includes an indication of the number of caregivers who acceptedthe alert 810; this is shown by element 814. In this case, one caregiverhas accepted the alert. Additionally, the alert 810 includes anindication of the number of caregivers who have rejected the alert 810(in this case, zero caregivers have rejected the alert 810).

FIG. 9 depicts a series of exemplary GUIs 900, 920, and 940 thatillustrate the ability of a caregiver to review an alert history for apatient. The GUI 900 depicts a general menu screen 905. The general menuscreen includes an alerts review 910 bar by which the caregiver canreview alerts related to the patient (e.g., patient Kathleen Wu). Uponselection of the alerts review bar 910, the user is taken to an alertsreview screen 915 that is similar to the alerts review screen 705 ofFIG. 7. The alerts review screen 915 includes a new alert area 922 and aprevious alert area 924 similar to the new alert area 722 and theprevious alert area 724 of FIG. 7. The new alert area 922 includes botha critical alert 926 and a non-critical alert 928. The previous alertarea 924 includes three critical alerts 930, 932, and 934. Uponselection of an alert, such as the alert 934, an alert detail screen ispresented as shown by alert detail screen 941 of the GUI 940.

The GUI 940 includes the alert review screen 915 and the alert detailscreen 941. The alert detail screen 941 includes the alert identifierand the alert status. The alert detail screen 941 further includes anotification 944 that the alert 934 was accepted and the time it wasaccepted. Additionally, it includes two forwarding indications 946 and948 that indicate that the alert 934 was forwarded twice and the timeswhen the alert 934 was forwarded.

The present invention has been described in relation to particularembodiments, which are intended in all respects to be illustrativerather than restrictive. Further, the present invention is not limitedto these embodiments, but variations and modifications may be madewithout departing from the scope of the present invention.

What is claimed is:
 1. A computing hardware device havingcomputer-executable instructions embodied thereon that, when executed,provide a method for-managing patient alerts, the method comprising:receiving, on the computing hardware device, an alert related to apatient, the computing hardware device associated with a first caregiverassigned to the patient; presenting the alert via the computing hardwaredevice, wherein the alert comprises selectable response options, whereinthe selectable response options comprises at least an accept option;receiving, at the computing hardware device, a selection of at least oneof the selectable response options; and executing a functionalitycorresponding to the at least one of the selectable response optionsselected at the computing hardware device.
 2. The computing hardwaredevice of claim 1, wherein the method further comprises providing anavailability status of one or more additional caregivers.
 3. Thecomputing hardware device of claim 1, wherein the multiple selectableresponse options comprises at least a reject option.
 4. The computinghardware device of claim 1, wherein the functionality corresponding tothe at least one of the selectable response options selected at thecomputing hardware device is an acceptance of the alert.
 5. Thecomputing hardware device of claim 1, wherein the alert comprises anindication of an alert level.
 6. The computing hardware device of claim5, wherein the alert level comprises a critical alert or a noncriticalalert.
 7. The computing hardware device of claim 1, wherein the alert isa pop-up message.
 8. The computing hardware device of claim 8, whereinthe pop-up message overlies other user interface elements of thecomputing hardware device.
 9. A computing hardware device havingcomputer-executable instructions embodied thereon that, when executed,provide a method for managing patient alerts, the method comprising:receiving, on the computing hardware device, an alert related to apatient, the computing hardware device associated with a first caregiverassigned to the patient; determining one or more additional caregivers;presenting an alert response interface via the computing hardwaredevice, wherein the alert response interface comprises multipleselectable response options, wherein the multiple selectable responseoptions comprises at least a reject option; and receiving, at thecomputing hardware device, a selection of at least one of the selectableresponse options.
 10. The computing hardware device of claim 9, whereinthe method further comprises providing an availability status of one ormore additional caregivers.
 11. The computing hardware device of claim9, wherein the multiple selectable response options further comprises atleast an accept option.
 12. The computing hardware device of claim 9,wherein the multiple selectable response options further comprises amessaging option, wherein selection of the messaging option initiates amessage screen.
 13. The computing hardware device of claim 9, whereinthe functionality corresponding to the at least one of the selectableresponse options selected at the computing hardware device is anacceptance of the alert.
 14. The computing hardware device of claim 9,wherein the alert comprises an indication of an alert level.
 15. Thecomputing hardware device of claim 14, wherein the alert level comprisesa critical alert or a noncritical alert.
 16. The computing hardwaredevice of claim 9, wherein the alert is a pop-up message.
 17. Thecomputing hardware device of claim 16, wherein the pop-up messageoverlies other user interface elements of the computing hardware device.18. A computer-implemented method, the method comprising: receiving, onthe computing hardware device, an alert related to a patient, thecomputing hardware device associated with a first caregiver assigned tothe patient; determining one or more additional caregivers; presentingan alert response interface via the computing hardware device, whereinthe alert response interface comprises multiple selectable responseoptions, wherein the multiple selectable response options comprises atleast a reject option and an accept option; and receiving, at thecomputing hardware device, a selection of at least one of the selectableresponse options.
 19. The method of claim 18, wherein the alert is apop-up message.
 20. The method of claim 18, wherein the multipleselectable response options further comprises a messaging option,wherein selection of the messaging option initiates a message screen.